本篇文章作為網站前端開發主題的第二篇，
我們將討論使用各種 plugin 時，常需要注意的共通引入事項。

--------系列簡介--------

網站系統可說是現在最多學子與新人想要入門的一個領域，
這個原本屬於新興的領域，這幾年來也累積許多年的知識與 pattern ，
在有限的環境（stateless）與有限的伺服器端、瀏覽器資源下，
成為許多人進入程式的一塊入門鐵板(?)。

這個系列希望能夠就網站系統設計幾個門檻著手，
這是設定給初心者作為學習，給同好們作為回顧，

重新認識有關網站系統的每個環節。
今天原訂的主題是「站在巨人的肩膀上，談常見可直接使用的網頁元件」，

不過因為很多元件在昨天分類中，都已經介紹過了，
所以今天要介紹的是元件使用上的注意事項。

將筆者使用元件時，常常會注意的幾件事情做個參考。

一般而言，一個前端元件大概會有包含幾個部份，
首先通常 css code 或 javascript code 是一定避不了的，

因為現成的元件通常都是一個在視覺上被裝飾過得東西，
理所當然的需要 JS 或 CSS 加以進行客製化。

另外因為有 JS code ，加上原生 JS code 提供的功能太少；

常常有時會因為原生的 JS 太難以開發，
所以使用其他函式庫協助開發，讓眼前的 JS 可以專司其職。

雖然說這不失為是一件好事，但是帶來的問題就是相依性。

像是相依於 prototype lib 的跟相依於 jQuery lib 的，
如果都載入的話就，反而會浪費資源做重複的事情，

但是如果不載入的話就只能選擇支援其中一種的實作，
所以相依性是否符合目前的專案，也是挑選的條件之一。

通常我們看到一個元件，第一件要先知道的是，
這個元件有沒有相依於什麼特定條件，

有些是相依於函式庫（這年頭大多是 jQuery base），
有些是限定特殊瀏覽器。

第二件事是他需要載入哪些資料，
通常會包含一個或多個 JS 檔，並且通常會提供壓縮過的版本。

如果是 UI 相關的，有可能會有 CSS 檔，
如果沒有 CSS 檔又有視覺上的效果，
那就可能是透過 inline css 寫在 JS 裡面。

另外針對某些特殊元件，特別是牽扯到資料流的，
可能還會有伺服器端元件要裝，
如 CKEditor ，檔案上傳需要伺服器端協助。

第三件事情是他需要配合什麼規範，
像是有些 plugin 可能會假設要有特定的 html 結構。

像是客製捲軸因為需要控制高度跟有地方可以放捲軸，
所以通常會希望你定義出 viewport 跟 container ，

並且兩者要遵守一定的規範。

另外有些東西可能會有一些一定程度的但書，像是做 Layout 的，
如做出圖片牆效果的 isotope ，可能會要求內容高度已經固定。

如果內容 image 或其他元素，之後再進行寬度或高度的變更，
可能會需要重新在之後再呼叫一次 api 讓他重新進行畫面的計算。

只要有流程通常就會有需要配合的地方，得要仔細閱讀跟瞭解才行。

第四個是他提供哪些選項跟事件你可以使用的，

通常很多套件雖然他做了很多功能，
但是關鍵的部份那個事件或功能他就是沒有開放出來，
這時候可能就會需要修改原始碼或者換另一個元件進行。

筆者的經驗是筆者使用的 plugin 要完全符合自己的需求，
大概有 50% 以上的比例都是需要修改 plugin source 的，

因為前端的需求往往是非常高度客製與靈活的，
要完全不修改而能合用，只有針對共用性很高的基本元素才有機會。

有句話說：
「 plugin 沒進專案時，看起來跟專案都是相似的，
但用到專案後，則各有各的例外。」

另外有些 plugin 可能會持續的需要伺服器端提供資料，
這些因為 plugin 而延伸的限定格式資料 API 的實作，也是一個點。

像是使用 GridView （ex.ExtJS Grid）的元件，
可能就需要製作 JSON 的伺服器端回應，能更方便操作元素。

而平常我們可能習慣的是直接進行頁面跳轉跟分頁之類的。

總之選擇 lib ，同時也可能會影響、決定很多事情，
在選擇時，應該以離自己既有專案比較接近的方向為主。

總言之一般而言，我們會先決定核心 lib （一般是 jQuery），
接著考慮伺服器端實作跟專案架構規劃，去選擇其中對應的 lib。

接下來就是在玩鬼抓人（開發者要遵循plugin 的規則），
或人抓鬼（開發者去修改 plugin 的規則）的遊戲。

直到作到專案預期的結果為止。

今天大概只是簡要介紹一些引入函式庫進專案的基本概念，
明天開始我們會進入具體前端程式的開發，到時候就會瞭解更多細節。

那麼，明天見。;)